home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Tools & Utilities
/
Collection of Tools and Utilities.iso
/
bbsutil
/
tick200.zip
/
TIC2NOTS.DOC
< prev
next >
Wrap
Text File
|
1990-02-19
|
16KB
|
349 lines
Betatic.doc
Tick 1.31 -
* Fixed a minor bug that could allow an invalid AKA to be
used in rare cases.
* First attempt at instituting the SECONDARY areas. If you
ever followed the AREA name in the TIC.CFG file with something,
you might have encountered the message about not finding the
secondary area. That was a result of code that was only par-
tially implemented. Now to explain what a secondary area is, and
how it works:
AREA c:\dir\dir2\boo SOFTDIST R13DIST
The line above is the start of an area block that declares a
primary area tag of SOFTDIST, and a secondary area called
"R13DIST". R13DIST MUST be defined as the primary tag of another
AREA block.
What will happen is this: If a file is received in
SOFTDIST, the file will be echoed to the nodes listed under
SOFTDIST (with a file-echo-tag of SOFTDIST), and to the nodes
listed in R13DIST (with a file-echo-tag of R13DIST). Files
received in R13DIST will NOT echo into SOFTDIST, unless SOFTDIST
is also a secondary area for R13DIST.
Files entering your node will be tossed to the SECONDARY
area's toss-to directory if a secondary area is defined. (It can
be the same as the primary area's directory.) The exception to
this is if STOPDUP is active. In that event, if the file has
been seen in the secondary area but not in the primary area, it
will toss to the primary area.
If STOPDUP is active, echo will be suppressed in any area
that has already seen the file. If the file has been seen in the
primary, but not the secondary area, only the secondary area will
receive the outbounds, and vice-versa. If the file has been seen
in BOTH areas, the inbound will be failed (renamed to *.BAD).
The Seenby's for BOTH areas will appear in all the generated
TICs. If the same node is listed in both primary and secondary
areas, the file will go to that node in the primary area only.
The code is not re-entrant. If the secondary area has its
own secondary area, a file sent in the primary area will not echo
all the way down to the 3rd area. This prevents circular defini-
tions.
So what is it good for? Several things that I can think of,
and probably a few more I haven't. In the SDS, only selected
nodes are given "*" capability in the national echos. Using
1
Betatic.doc
secondary areas, you could have all nodes in a region link into
SOFTDIST via the local echo R13DIST (or whatever you might chose
to call it). The local nodes can all be given "*" capability to
hatch to each other within R13DIST. The files will flow locally,
but not enter the national echo unless the RC hatches them into
that echo. You might choose to use the secondary area feature to
merge two echos locally, while maintaining individual echo feeds
for those who want or need the distinction. To do that, you'd
have the same secondary area for 2 (or more) primary areas.
Another use may come into play when pre-release is a reality.
* Please note that HATCH now asks for "release in how many
days?" That is there for pre-release, and is still disabled.
(That code is partially there in HATCH, but not yet in TICK.)
You may bypass the prompt by including the command line parameter
"/R0", to tell HATCH to release it in "0" days, (ie - NOW).
* Defined a new Files.bbs specification. %8 will print the
name of the PRIMARY area (that the file was received in) to the
Files.bbs
* Fixed the Doc file for the next release, to correct the
keyword LINEFMT to the proper form, LISTFMT.
~~~~~~~~~~~~~~~~~~~~
Tick 1.32 -
* Hopefully have closed a hole in the COPY routine where a
file could have been copied to a full disk and error not have
been reported. I wonder if this was the cause for occasions
where TIC's have been sent without the files?
* Version 1.31 of HATCH can cause some DUPs if both primary
and secondary areas are active and have a duplicated node listed
in both. This version should fix that.
* Have added support for zones 1 - 32767. This involved a
lot of changes, so look for any flaky operations.
* If you receive a pre-release file, the planned release
date should be logged.
* Tick now partially implements pre-release!!! Here's how
it works: Within an AREA block, those nodes that may receive a
pre-release file before the release date should have a "P" flag
in the flag field. When you HATCH a file, the prompt for
"Release in how many days?" is now active. If you just press
<enter>, the file is a normal file and is not delayed. If you
have a file that you want to send as a pre-release, place the
file into the QDIR directory. (QDIR should NEVER be a
2
Betatic.doc
downloadable directory). When the prompt for release days comes
up, answer with the number of days to delay. (You may bypass the
prompt by using the /Rx command line option, where "x" is the
number of days to delay. /R2 delays 2 days, /R0 is a normal
release.
If you have specified a pre-release file, then only those
nodes that have a "P" flag will get the file immediately. Please
note that only nodes that are also running TICK 1.32 or higher
should be given "P" status. Those nodes will have TIC's and at-
taches created. The TIC's will have the seenbys for all nodes
that will eventually receive the file. In addition, there will
be a "*.TOK" file also created in the HOLD directory. That file
resembles a TIC closely, but has the seenby's for the pre-release
nodes only.
Each time you run TICK 1.32+, the program will first scan
the HOLD directory for TOK files. If it finds any, it examines
them to see if the associated pre-release file is "ripe" yet.
When it is, the file is moved to the destination (downloadable)
directory, the FILES.BBS is updated, and new attaches are created
to those nodes that do not have the "P" flag.
THIS IS ONLY PARTIALLY IMPLEMENTED YET ... What I will need
to do is to provide for the case where the file is "ripe" but all
the "P" flagged nodes have not yet received the file. In that
instance, the existing file attaches will become invalid when the
file is moved. I need to write code that will look for any un-
delivered attaches for that file, and alter the FLO or MSG to
point to the proper place. Right now that hasn't been coded, so
if all "P" nodes have not had their files delivered before the